The development of client software applications typically involves a trade-off between leveraging the latest software platform for feature richness and the reuse of existing software code. With the proliferation of mobile clients and modern user interface (UI) libraries for JavaScript, software development teams are required to rewrite code over and over again, either via parallel development of similar applications for different platforms or by excluding less prominent platforms.
The ability to write software code once and use it on multiple different platforms greatly enhances the efficiency of software application development. A perfect adaption to the native platform is crucial, especially for user interfaces, the acceptance of which depends on a smooth integration of the standard look and feel of the platform.
Some platform independent libraries already exist for languages such as C++ or Java, which adapt very well and use native application programming interfaces (APIs) to provide good user experience (e.g., Java SWT or C++ boost). However, such libraries require the same base language to be executed on the target platform. This is not always possible, especially if the requirements are that the programming code has to be a base for other application developers who want to use the platform's primary language, such as JavaScript in the web browser or Node.js or Objective C for Apple devices. Developers are typically tied to platforms with the same language.
Some solutions to the problem include a low-level transformation of virtual machine (VM) byte code from one machine to another. This solution works only when a compiler that transforms the source code to VM byte code is provided and the virtual machines for source and target systems are very similar (e.g., Java VM and Microsoft .net VM). They need to be similar in various aspects, such as primitive types, garbage collection and memory management, function calling, class inheritance features, etc. Since human readable source code is not available at the target system, debugging and auto suggest features for editing the client/application code in the integrated development environment (IDE) may be restricted or even impossible.
Another solution is to use a highly specialized converter that translates one language to another. Such solution is typically restricted to a one-to-one relationship between source and target platforms (e.g., Java to JavaScript) and is often combined with the requirement to re-implement all or major parts of the APIs at the source platform, which may also cause legal issues with regard to intellectual property rights.
Yet another solution may be to define a new proprietary programming language. This solution lacks support from an existing toolchain (probably no support at all) and presents a high barrier for developers to learn and use a new proprietary language. The efficiency gained by transcompiling is lost again by a very inefficient software development cycle. Additionally, there is probably no existing runtime environment that can be used to execute, test and debug the source code.